-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Skip no-op drop glue #142508
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Skip no-op drop glue #142508
Conversation
@bors2 try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Skip noop drop glue Since #122662 this no longer gets used in vtables, so we're safe to fully drop generating these empty functions. Those are eventually cleaned up by LLVM, but it's wasteful to produce them in the first place. Opening this for a perf run before asking for review.
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (d28feb0): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.5%, secondary 2.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 1.1%, secondary -0.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.3%, secondary -1.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 757.645s -> 756.931s (-0.09%) |
c839507
to
1573ec4
Compare
//~ MONO_ITEM fn <Struct<u32> as Trait>::foo | ||
//~ MONO_ITEM fn <Struct<u32> as Trait>::bar | ||
let r1 = &s1 as &Trait; | ||
r1.foo(); | ||
r1.bar(); | ||
|
||
let s1 = Struct { _a: 0u64 }; | ||
//~ MONO_ITEM fn std::ptr::drop_in_place::<Struct<u64>> - shim(None) @@ instantiation_through_vtable-cgu.0[External] | ||
//~ MONO_ITEM fn <Struct<u64> as Trait>::foo | ||
//~ MONO_ITEM fn <Struct<u64> as Trait>::bar | ||
let _ = &s1 as &Trait; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to me this test is mostly a duplicate of the unsizing test, so I'm skipping updating it with its own drop glue variant -- seems like that's covered there. Maybe worth deleting one of these entirely in a follow-up PR though.
This comment has been minimized.
This comment has been minimized.
1573ec4
to
9549f6b
Compare
r? @fee1-dead rustbot has assigned @fee1-dead. Use |
Some changes occurred in tests/codegen/sanitizer cc @rcvalle |
The image benchmark seems spurious given the graph, so @bors r+ rollup |
@bors r+ |
Skip no-op drop glue Since #122662 this no longer gets used in vtables, so we're safe to fully drop generating functions from vtables. Those are eventually cleaned up by LLVM, but it's wasteful to produce them in the first place. This doesn't appear to be a significant win (and shows some slight regressions) but seems like the right thing to do. At minimum it reduces noise in the LLVM IR we generate, which seems like a good thing.
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
dcac9c3
to
beb9227
Compare
@bors2 try jobs=x86_64-gnu-nopt |
Skip no-op drop glue Since #122662 this no longer gets used in vtables, so we're safe to fully drop generating functions from vtables. Those are eventually cleaned up by LLVM, but it's wasteful to produce them in the first place. This doesn't appear to be a significant win (and shows some slight regressions) but seems like the right thing to do. At minimum it reduces noise in the LLVM IR we generate, which seems like a good thing. try-job: x86_64-gnu-nopt
💔 Test failed
|
beb9227
to
b4568d9
Compare
@bors r=fee1-dead |
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 111e9bc (parent) -> be19eda (this PR) Test differencesShow 8 test diffsStage 1
Stage 2
Additionally, 6 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard be19eda0dc4c22c5cf5f1b48fd163acf9bd4b0a6 --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Finished benchmarking commit (be19eda): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 1.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.5%, secondary -2.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.3%, secondary -1.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 689.093s -> 689.346s (0.04%) |
Since #122662 this no longer gets used in vtables, so we're safe to fully
drop generating functions from vtables. Those are eventually cleaned up
by LLVM, but it's wasteful to produce them in the first place.
This doesn't appear to be a significant win (and shows some slight regressions) but
seems like the right thing to do. At minimum it reduces noise in the LLVM IR we generate,
which seems like a good thing.